In communication networks using packet data transport, individual data packets carry in a header section an information needed to transport the data packet from a source application to a destination application. The actual data to be transmitted is contained in a payload section.
The transport path of a data packet from a source application to a destination application usually involves multiple intermediate steps represented by network nodes interconnected through communication links. These network nodes, called packet switches or routers, receive the data packet and forward it to a next intermediate router until a destination network node is reached which will deliver the payload of the data packet to the destination application. Due to contributions of different protocol layers to the transport of the data packet, the length of a header section of a data packet may even exceed the length of the payload section.
Data compression of the header section may therefore be employed to obtain better utilization of the link layer for delivering the payload to a destination application. Header compression reduces the size of a header by removing header fields or by reducing the size of header fields. This is done in a way such that a decompressor can reconstruct the header if its context state is identical to the context state used when compressing the header. Header compression may be performed at network layer level (e.g. for IP headers), at transport layer level (e.g. for User Datagram Protocol (UDP) headers or Transport Control Protocol (TCP) headers), and even at application layer level (e.g. for Hyper Text Transport Protocol (http) headers).
The context of the compressor is the state it uses to compress a header. The context of the decompressor is the state it uses to decompress a header. Either of these or the two in combination are usually referred to as “context”, when it is clear which is intended. The context contains relevant information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression. Moreover, additional information describing the packet stream is also part of the context, for example information about how the IP identifier field changes and the typical inter-packet increase in sequence numbers or time stamps.
Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common. In the IETF (Internet Engineering Task Force) specification RFC 3095, a robust header compression (ROHC) scheme is specified as a highly robust and efficient header compression scheme for RTP/UDP/IP (Real Time Transport Protocol, User Data-gram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. Generally, a packet corresponds to a unit of transmission and reception, e.g. a protocol data unit. The packet is compressed and then decompressed e.g. by ROHC. The packet stream corresponds to a sequence of packets where the field values and change patterns of field values are such that the headers can be compressed using the same context. When the context of the decompressor is not consistent with the context of the compressor, decompression may fail to reproduce the original header. This situation may occur when the context of the decompressor has not been initialized properly or when packets have been lost or damaged between compressor and decompressor. Context repair mechanisms are mechanisms which bring the contexts in synchronization when they were not. This is needed to avoid excessive loss due to context damage.
The main reason why header compression can be done at all is the fact that there is significant redundancy between header fields, both within the same packet header but in particular between consecutive packets belonging to same packet stream. By sending static field information only initially and utilizing dependencies and predictability for other fields, the header size can be significantly reduced for most packets. Relevant information from past packets is then maintained in the context. The context information is used to compress or decompress subsequent packets.
Thus, in conventional header compression schemes, it is typically necessary to send full packet headers in the first packet(s) of a connection.
However, Internet network layer services (Internet Protocol Service) are unreliable. IP does not guarantee datagram delivery, in-order delivery of datagrams, and integrity of the data in the datagrams. In IP services, datagrams can overflow router buffers and never reach their destination, datagrams can arrive out of order, and bits in the datagram can get corrupted.
TCP (Transmit Control Protocol) creates a reliable data transfer service on top of IP's unreliable best-effort service. Once a-TCP connection is established between the two end-systems, the application process at the sender provides bytes to the senders TCP send buffer. TCP grabs portions of a maximum segment size (MSS), encapsulates each portion within a TCP segment, and passes the segments to a network layer for transmission across the network. The TCP congestion window regulates the times at which the segments are sent into the network. Initially, during a phase of a congestion control procedure, the congestion window increases exponentially, i.e. the congestion window is initialized to one MSS, after one round trip time (RTT) the window is increased to two segments, after two RTTs the window is increased to four segments, after three RTTs the window is increased to eight segments, etc. This phase of the algorithm is called slow start because it begins with a small congestion window equal to one MSS. The slow start phase ends when the window size exceeds the threshold value. Once the congestion window is larger than the current threshold value, the congestion window grows linearly rather than exponentially. This has the effect of increasing the congestion window by one in each RTT for which an entire windows worth of acknowledgements arrives.
Due to the fact that, even if header compression schemes are used, a full (non-compressed) packet header of considerable length is sent in the first packet(s) of a connection, a high error probability must be assumed for transmission over lossy links. Consequently, the chance of going into the slow start phase and delaying the transaction is high.